(原文出處: 連結)
在應用程式以及商業策略中,「效能」經常被忽視,它從來都不是優先考量或是被特別看重的層面,為什麼呢?因為通常人們的心態是:
有誰也曾經講過類似的話?《The Art of Computer Programming》的作者 Donald Knuth 博士有句名言說道:「(程式)過早進行優化是萬惡之源。」
不過到了現在看來,這句話還是對的嗎?
為什麼現在應該及早注意「效能」這件事?
提早優化絕對不是什麼萬惡的根源,優化是一種「態度」。它像是一種生活方式、一種致力於讓未來更輕鬆的心態。在採購硬體時,我們總是想防患於未然,所以會選擇在當時比較高規格的CPU,覺得這樣才可以多用個幾年。那為什麼我們不用一樣的心態來面對程式的優化呢?
伺服器通常非常昂貴,而且不只是硬體本身的支出,別忘了還有技術維護的人事成本。在這些資源上加碼往往都是最後不得已的手段,它的確是最簡單的解決方法,卻也是最爛的一種。請想像在年終的預算審查會上,你要怎麼跟老闆解釋你花了大部分的預算在買機櫃?其實,你可以把錢花在更好的地方,擴充硬體永遠都不會真正解決問題,直到你發現應用程式無法快速地擴展(scalable)時,這時就算有錢也解決不了。
我們總是太晚進行優化
歷史告訴我們,人類總是在遇到問題時才發現那是一個問題,然後再費盡千辛萬苦設法解決。
拿最近的一個例子來說,Guru3d(一個有名的科技新聞網站)由於突然流量過大,使得網頁超載而當掉。根據他們後來的說法:「三個禮拜前,當最早關於Pascal的文章上線時,觀看的人數有讓我們小小驚訝一下,不過隨後幾分鐘,對於文章的相關評論使得我們的前端流量暴增2500%,讓我們的server不堪負荷。」
一般的產品開發程序
有誰曾經在半夜埋頭開發程式,原只是為了解決一些重複的工作 (或是單純為了「好玩」)而只對朋友或公司內部發布,後來卻被廣泛傳散而一發不可收拾?至少到目前為止,我看過太多類似的程式原本只在某個員工的電腦裡面進行開發,最後卻超乎預期地被許多人廣泛使用。最後的結果是我們開始依賴這個「安裝在某人電腦」的軟體。假如某天,這個程式當掉了、那個人又剛好休假,我們該怎麼辦?如果我們試圖把這個好用的程式從這個人的電腦裡面拿出來,在這段移植的時間,全部人就都沒得用而陷入尷尬的局面。這時我們才想說要怎麼擴張它、要怎麼進行優化?一切都太遲了!這對企業來說會造成非常大的影響,往往只能花更多錢去改善跟彌補。
那為什麼我們不一開始就進行優化?有一次,我問我前公司的技術主管,為什麼我們的app要選擇某個特定的程式庫(libarary)?他沒有正面回應我,只說了「因為大家都用這個,而且它是一套標準」。是它的性能比較好嗎?這位主管也一知半解。直到我們開始佈署這個app時(或者套用在比較大規模的組織上),才發現到問題—這個app太慢了,根本不會有人想要用它。那為什麼我們不在一開始做出更好的選擇?
太晚優化的代價
現在這個app已經安裝完成也開始運作了,每個已上架的app都有一些規則需要遵守,我們不能就這樣把它下架然後進行程式維護,甚至在沒有獲得批准前我們不能做任何修改。
但這個程式已經太多瑕疵了!
我們必須在一個測試環境下進行測試,模擬可能的使用者人數,再試著去debug。到底問題在哪裡?是資料庫嗎?還是前端的使用者介面?有沒有可能是web server跟硬體出狀況?不得而知。我們必須要進行一連串的分析、搜集一大堆資料,這些通通都需要花錢。當然,我們可以在上線前進行這些測試,並在測試的過程中試圖避免這些問題(真實世界中,使用者的行為是很難預測的),不過這樣的花費仍然很高。
最根本的問題在哪?
真正的問題在於,我們經常陷入最基本的錯誤當中,在設計跟概念上往往就已經出問題,拿剛剛app測試的例子來說,為什麼我們不一開始就建立一個多線的程式架構(multi-threading)?我們沒想到是因為相信自己能夠將程式規模化、況且這樣的架構不常被採用,所以也常被忽略。這就是問題點所在,我們總是低估了可能產生的需求,而我們需要想的更多、更遠。
要怎麼解決?
我們往往都是開發出一套程式,然後再進行補強,就像是在程式的漏洞貼上ok蹦一樣,卻沒有解決最根本的問題。癥結點往往都藏在最深處,偽裝成是某個小bug讓你的程式變慢。
真正從根本上的解決方法,是一開始就抱持著「優化的心態」,為什麼我們不一開始就選擇一個更有效率的程式庫或是web server?這樣做不會花你太多時間,而且透過搜集資料與比較,你可以有更多的選擇。
(圖片來源: Linux Web Server Performance Benchmark – 2016 Results)
最近的趨勢是「行動裝置至上」,這是什麼意思?從前我們都只用桌電,直到近年來手機、平板成為大宗,使得人們在開發軟體時將行動裝置設為首要考量,要設計出手機也能操作自如的介面。為什麼我們有這樣的改變? 並不是因為行動裝置開始比電腦更重要,而是因為我們觀察到了這樣的現象,所以必須事先考量行動裝置的呈現方式。同樣的,我們何不用這樣的心態,在一開始就思考優化的重要性呢?
更多效能改革觀點,敬請期待!
HyperConnezion 的「效能改革系列專欄」希望能夠屏除人們對於效能的迷思,並引導大家要怎麼擁有正確的心態做出正確的決定。在下一篇文章中,我們將討論用不同的策略去確保網頁在任何時候都保持高效能,而不是在出狀況之後才去設法補救。敬請期待!
【作者簡介】
Harry Chan,HyperCconnezion創辦人,於香港出生並於澳洲接受教育。於IT產業的創業經驗近5年半,也曾經於澳洲業界和政府單位從事IT管理職務約6年。長期關注雲端、網路、IT管理、企業應用等領域。
【關於HyperConnezion】
HyperConnezion是一個提供雲端解決方案和IT管理服務的公司,致力於成為各家企業的最佳IT夥伴。無論是個人、新創、中小企業乃至於大型企業,HyperConnezion均能提供客戶量身打造的IT顧問建議與服務。目前HyperConnezion在雪梨、香港、台北均設有據點。更多消息請上:
不錯的文章,但我認為...Dr. Knuth說的過早進行優化,應該指的是程式碼的優化,和效能優化是不同事件。
優化程式碼和優化效能,並不一定是相同的。優化程式碼不見得能優化效能,優化效能不一定能優化程式碼。
效能優化越早進行越好,在系統還沒開發前,就要先想好優化的目標,建立效能基準線(Baseline)。